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(54) Methods and apparatus for managing devices without network attachments 



(57) A system and method for monitoring and man- 
aging devices on a network. The system and method 
preferably comprises a proxy server connected to the 
network and a managed device connected to the proxy 
server. The system further comprises storage means for 
storing a device management application program as- 
sociated with the managed device, and a management 
station in communication with the managed device via 
the proxy server and in communication with the storage 
means. The management station preferably is config- 



ured to retrieve the device management application pro- 
gram from the storage means and process the device 
management application program. As the management 
station,processes the device management application 
program, the management station is able to monitor and 
manage the managed device. In particular, the manage- 
ment station can send management commands to a 
controller of the managed device via the proxy server, 
and the management station can receive notifications 
from the managed device, also via the proxy server. 



CM 
< 
CM 

CD 



Q. 
LU 



I/O 
Management 
Station^- 1 12 



SUMP 
Management 
Station^— 116 




I/O 
Management 
Station 



' k I DitkFarm ! 

vsr j fig.. 1 



Printed by Jouve. 75001 PARIS (FR) 



EP 1 067 732 A2 



Description 

CROSS-REFERENCES TO RELATED 
APPLICATIONS 

[0001] This application is being filed concurrently with 
related U.S. patent applications: LSI Logic Docket 
Number 98-054, entitled "Methods and Apparatus for Is- 
suing Updates to Multiple Management Entities"; LSI 
Logic Docket Number 98-049, entitled "Methods and 
Apparatus for Performing Mass Operations on a Plural- 
ity of Managed Devices on a Network"; LSI Logic Docket 
Number 98-068, entitled "Methods and Apparatus for 
Managing Heterogeneous Storage Devices"; LSI Logic 
Docket Number 98-110, entitled "Methods and Appara- 
tus for Committing Configuration Changes to Managed 
Devices Prior to Completion of the Configuration 
Change 0 ; LSI Logic Docket Number 98-112, entitled 
"Platform Neutral Data Storage Management Method 
and Apparatus"; and LSI Logic Docket Number 98-111, 
entitled "Apparatus and Method for a Computer Man- 
agement Storage System", all of which are incorporated 
herein by reference. 

BACKGROUND OF THE INVENTION 

[0002] The present invention relates generally to 
methods and apparatus for managing devices on a net- 
work, and more particularly to a network based system 
and software for monitoring and managing devices that 
are not attached directly to the network, but are proxy 
attached to the network via another device. 
[0003] Network computing systems typically require 
a variety of devices to construct and maintain a working 
storage system. In addition, companies with large net- 
works typically have a number of different storage sys- 
tems, many of which can be manufactured by different 
companies and/or run on different versions of operating 
software. Storage system devices may include, but are 
not limited to, host adapters, I/O chips, disk enclosures, 
and bridge controllers, to name a few. 
[0004] Each of these components traditionally are 
managed by proprietary software that is supplied by its 
manufacturer. In addition, there are a number of third 
parties which have developed network management 
frameworks, such as Hewlett-Packard's Open View, 
IBM's NetFinity, and Computer Associates' Unicenter. 
Unfortunately, however, while these third party frame- 
works provide great benefit to the management of ap- 
plications, servers, and network equipment, they have 
little success in managing storage devices because no 
single standard exists for configuring and monitoring 
storage devices produced by different manufacturers, 
as well as different versions of storage devices pro- 
duced by the same manufacturer. Standards such as 
desk top management interface (DMI) and simple net- 
work management protocol (SNMP) are able to manage 
simple devices such as host adapters and the like, but 
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they fall short when applied to complex devices such as 
disk array controllers. As one skilled in the art will ap- 
preciate, it is not likely that a standard for managing disk 
array controllers will be created in the future, because 

s unlike host adapters and disk subsystems, each disk ar- 
ray vendor is constantly releasing proprietary features 
to distinguish itself in the marketplace. It is well known 
in the art that devices, such as storage systems, can 
connect directly to the network using, for example, an 

10 ethemet or other suitable network adapter. Each device 
connected directly to the network has an IP address 
identifying itself on the network. Thus, devices commu- 
nicating with these direct attached devices easily can 
locate them because of their unique IP addresses. 

is [0005] As one skilled in the art will appreciate, many 
devices, such as low end storage systems, or the like, 
do not connect directly to the network, but are connect 
to a server or other workstation via PCI, SCSI, fibre 
channel, USB, firewire, or the like. Thus, the only attach- 

20 ment to the network that these devices have may be 
through the proxy server device. Accordingly, it is diffi- 
cult for other devices on the network to locate these de- 
vices, because they don't have network IP addresses. 
Only the proxy server attached to the network has an I P 

25 address. It is particularly difficult to manage these proxy 
attached devices with online management frameworks, 
because the management stations cannot send suitable 
management commands to the proxy attached devices. 
Thus, what is needed is a management framework 

30 which can locate these proxy attached devices, and a 
system which can communicate management com- 
mands between a management station the proxy at- 
tached devices. 

35 SUMMARY OF THE INVENTION 

[0006] According to the invention, a system and meth- 
od for monitoring and managing devices on a network. 
The system and method preferably comprises a proxy 

40 server connected to the network and a managed device 
connected to the proxy server. The system further com- 
prises storage means for storing a device management 
application program associated with the managed de- 
vice, and a management station in communication with 

45 the managed device via the proxy server and in com- 
munication with the storage means. The management 
station preferably is configured to retrieve the device 
management application program from the storage 
means and process the device management application 

so program. As the management station processes the de- 
vice management application program, the manage- 
ment station is able to monitor and manage the man- 
aged device. 

[0007] In accordance with one preferred embodiment 
55 of the present invention, the managed device preferably 
is connected to the proxy server by a suitable commu- 
nication connection. The communication connection 
may comprise peripheral component interconnect 
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(PCI), small computer system interface (SCSI), univer- 
sal serial bus (USB), fiber channel, firewire and the like. 
[0008] I n accordance with yet another embodiment of 
the present invention, the managed device preferably 
includes a controller for controlling the managed device, s 
In accordance with this particular aspect of the present 
invention, when the management station processes the 
device management application program, the manage- 
ment station is able to send management commands to 
the controller via the proxy server. Preferably, the man- 10 
aged device is a storage system. 
[0009] I n accordance with yet another embodiment of 
the present invention, the proxy server preferably in- 
cludes a device mapper which locates devices connect- 
ed to the proxy server and assigns a TCP/IP port to each is 
of the devices. Thus, when the device management ap- 
plication program of the management station sends 
management commands to the controller of the man- 
aged device, the device management application pro- 
gram first sends the management commands to the 20 
proxy server, and the device mapper in the proxy server 
routes the management commands to the managed de- 
vice. 

[001 0] In accordance with yet another embodiment of 
the present invention, the device management applica- 25 
tion program preferably communicates with the proxy 
server using a first communication protocol, and the 
proxy server communicates with the managed device 
using a second communication protocol. Thus, the 
proxy server includes a protocol converter for converting 30 
communication messages directed from the device 
management application program to the managed de- 
vice from the first communication protocol to the second 
communication protocol, and for converting communi- 
cation messages directed from the managed device to 35 
the device management application program from the 
second communication protocol to the first communica- 
tion protocol. Preferably, the first communication proto- 
col is remote procedure call (RPC) and the second com- 
munication protocol is universal transport mechanism 40 
(UTM), and the protocol converter comprises an RPC- 
to-UTM conversion application. 
[001 1 ] A more complete understanding of the present 
invention may be derived by referring to the Detailed De- 
scription of Preferred Embodiments and claims when *s 
considered in connection with the figures, wherein like 
referenced numbers refer to similar items throughout 
the figures. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0012] 

Fig. 1 is a schematic diagram of a network having 
various storage systems and storage management 
stations; 

Fig. 2 is a schematic diagram of a network having 
a management station, which accesses manage- 



ment application programs stored in an application 
repository storage area connected to the manage- 
ment station; 

Fig. 3 is a schematic diagram of a network having 
a management station, which accesses manage- 
ment application programs stored in an application 
repository storage area connected to a network; 
Fig. 4 is a schematic diagram of a network having 
a management station, which accesses manage- 
ment application programs stored on the storage 
system or device being managed by the manage- 
ment station; 

Fig. 5 is a block diagram illustrating various devices 
residing on a network and their associated software 
components; 

Fig. 6 is a drawing of a sample user interface screen 
of a discover-monitor application program; 
Fig. 7 is a drawing of a sample user interface screen 
of a storage system management application pro- 
gram; 

Fig. 8 is a flow diagram illustrating start-up process- 
es of a discover-monitor application program and a 
storage system management application program: 
Fig. 9 is a flow diagram illustrating a process of cre- 
ating a volume on a storage system; 
Fig. 10 is a flow diagram illustrating a process of 
replicating the configuration of one storage system 
to another storage system; 
Fig. 11 is a flow diagram illustrating a process of 
performing a mass operation on multiple storage 
systems on a network; 

Fig. 1 2 is a flow diagram illustrating a validity check- 
ing scheme performed by the process of Fig. 10; 
Fig. 1 3 is a flow diagram illustrating a process of 
reporting events from a storage system to a man- 
agement station; 

Fig. 14 is a flow diagram illustrating a process of a 
managed entity broadcasting configuration updates 
to a plurality of management devices; 
Fig. 1 5 is a flow diagram illustrating how a manage- 
ment device issues management commands to 
managed entities and receives configuration up- 
date information from managed entities; and 
Fig. 16 is a flow diagram illustrating a process of 
committing configuration changes prior to the com- 
pletion of a long term event. 

DESCRIPTION OF THE SPECIFIC EMBODIMENTS 



[0013] The present invention relates generally to 
methods and apparatus for managing devices on a net- 
work. More particularly, the present invention relates to 
a system and software for monitoring, configuring and 
managing heterogeneous storage systems on a net- 
work using a single management application residing on 
one or more management stations. 
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[0014] While the present invention disclosed herein 
refers particularly to storage systems, it should be ap- 
preciated that the management systems and applica- 
tions of the present invention can be used to manage a 
wide variety of devices on a network, including worksta- 
tions, servers, and other suitable I/O devices. Thus, the 
present invention relates to a management system and 
applications which have a single user interface for man- 
aging network devices, and which can interact with cur- 
rently existing management frameworks, such as 
Hewlett-Packard's OpenVlew, IBM's NetFinity and 
Computer Associates' Unicenter, to name a few. Finally, 
the present invention preferably utilizes platform -inde- 
pendent technologies, such as Java and Java run-time 
environments, so that the particular network architec- 
ture, and workstation and server platforms on the net- 
work are irrelevant. 

System Overview 

[0015] The present invention comprises a device-in- 
dependent management framework which supports de- 
vice-specific management applications. The framework 
preferably comprises an application that implements a 
common graphical user interface that is used to manage 
all I/O devices in an enterprise or on a network. Prefer- 
ably, at the start of a day, the management framework 
discovers all I/O devices in the enterprise and displays 
them, either by physical connectivity, or by logical asso- 
ciation. The discovery process can be conducted man- 
ually by a user, or it can occur automatically. For each 
distinct device type being managed or configured, a 
unique management application preferably is loaded, 
thus giving the framework the ability to understand de- 
vice-specific management tasks. Finally, because the 
architecture gives the management framework the abil- 
ity to communicate with all I/O devices on the enterprise, 
operations such as "firmware upgrades" may be per- 
formed en mass to common device types. 
[001 6] Referring now to Fig. 1 , a system 1 00 is shown 
embodying the present invention. In particular, system 
100 preferably comprises a local area network 102, a 
plurality of storage systems 104-110, an I/O manage- 
ment station 112, a desktop management interface 
(DMI) management station 114, and a simple network 
management protocol (SNMP) management station 
116. In addition, network 1 02 may be connected to other 
enterprise or company networks located in remote are- 
as either via direct telephone links or, as illustrated in 
Fig. 1, through a larger network, such as the Internet 
118, or the like. For simplicity, Fig. 1 merely shows net- 
work 102 being connected to a storage management 
station 120 through Internet 118, but as one skilled in 
the art will appreciate, storage management station 1 20 
may be a single device connected to Internet 118, or 
storage management station 1 20 may be a device on a 
network in a remote location connected to network 102 
via the Internet. In any event, the purpose of Fig. 1 is to 
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illustrate that the management framework of the present 
invention may be used on local area networks, as well 
as on wide area networks and with remote access de- 
vices. 

5 [0017] Storage systems 104-110 may comprise any 
suitable storage system, such as file servers, disk farms, 
RAID systems, and the like. In addition, the storage sys- 
tems may comprise controllers which connect directly 
to network 1 02 or the storage systems may be connect- 

10 ed to network 102 through a computer server. Fig. 1 il- 
lustrates a number of different types of storage system 
configurations which may reside on a network. Howev- 
er, the configurations illustrated in Fig. 1 do not illustrate 
all the storage system configurations, and thus, the 

15 present invention is not limited to the illustrated embod- 
iments. 

[0018] Still referring to Fig. 1, the various embodi- 
ments of storage systems 104-110 illustrated in Fig. 1 
will now be discussed. In particular, storage system 1 04 

20 preferably comprises a RAID storage system which in- 
cludes a server 122 and a plurality of disk drives 124 
connected to server 1 22. In accordance with this partic- 
ular embodiment, the processor of server 1 22 preferably 
acts as the RAID control device for storage system 1 04. 

25 in this manner, the RAID control software preferably is 
stored, either on disks 124 or within internal storage of 
server 122 and is processed by server 122 during oper- 
ation of the storage system. Disks 1 24 may be connect- 
ed to server 122 by any number of connection means 

30 126, such as fiber channel, SCSI, PCI, USB, Firewire, 
or the like. Server 1 22 preferably is connected to net- 
work 102 via well-known network connection means. 
[001 9] Like storage system 1 04, storage systems 1 06 
and 108 also preferably comprise RAID storage devic- 
es es. However, instead of the server acting as the control- 
ler for the RAID storage system, the storage systems 
preferably include their own controllers 128 and 130, 
which preferably are connected to servers 1 32 and 1 34 
via PCI bus connections 136 and 138, respectively. 

40 Thus, the storage system control functions for storage 
systems 106 and 108 preferably are performed by con- 
trollers 1 28 and 1 30, respectively. While controllers 1 28 
and 1 30 are illustrated as being separate from the RAID 
disk farm or disk array 140, one skilled in the art will 

45 appreciate that controllers 1 28 and 1 30 may reside with- 
in the enclosure of disk farm 140. Alternatively, control- 
lers 128 and 130 may be configured as co-processors 
within servers 132 and 134, respectively. 
[0020] As illustrated in Fig. 1 , controller 1 28 of storage 

so system 106 and controller 130 of storage system 108 
are not connected directly to network 102, but are con- 
nected to the network via servers 1 32 and 1 34, respec- 
tively. With this particular configuration, it is difficult for 
a management device to locate the storage system con- 

55 trollers 128, 130 connected to servers 132, 134, and 
thus, it is difficult to send management commands to the 
storage system controllers. However, as discussed in 
more detail below, servers 132 and 134 preferably in- 
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elude a layer of software which converts requests from 
the I/O management stations 112, 120 into command 
packets which are delivered to controllers 128 and 130 
and which can be understood and processed by the con- 
trollers. 

[0021 ] Storage system 1 1 0 also preferably comprises 
a RAID storage system having an independent RAID 
storage controller 142. However, in this particular em- 
bodiment, storage controller 142 preferably includes a 
network attachment means 144, so that it can attach di- 
rectly to network 102. In addition, as illustrated in Fig. 
1, controller 142 may be connected to a server 146 via 
a proxy I/O bus 148, such as a SCSI or Fibre Channel 
bus. In this manner, storage management stations 112, 
120 can issue management commands directly to stor- 
age controller 142 via network 102, or they can issue 
management commands through server 1 46 and across 
proxy I/O bus 1 48. As with the PCI attached controllers 
in storage systems 106 and 108, if access to controller 
1 42 is through server 1 46 and across proxy I/O bus 1 48, 
server 146 preferably includes a layer of software con- 
figured to convert requests from storage management 
stations 112, 120 to command packets which can be re- 
ceived and processed by controller 1 42. While controller 
142 appears to be separate from the RAID storage de- 
vice 150, one skilled in the art will appreciate that con- 
troller 142 may be configured within the disk enclosure 
of device 150. 

[0022] As illustrated in Fig. 1 , in addition to storage 
management stations 112, 120, system 100 also may 
include other network management devices, such as a 
desktop management interface (DM I) management sta- 
tion 114 and a simple network management protocol 
(SNMP) management station 116. In addition, other 
third party management stations, such as Hewlett-Pack- 
ard's OpenView, Computer Associates' Unicenter, 
IBM's NetFinity, and/or Microsoft's Microsoft Manage- 
ment Console, may be attached to network 1 02. Thus, 
the present invention is not limited to the illustrated em- 
bodiment. 

[0023] In accordance with a preferred embodiment of 
the present invention, I/O management stations 112, 
120 may comprise any suitable computer workstation 
running on any operating system platform. For example, 
I/O management stations 112, 120 may run on Micro- 
soft's Windows or NT platforms, Apple's Macintosh plat- 
form, a Unix platform, or the like. Thus, in order for I/O 
management stations 112, 120 to process the manage- 
ment applications associated with each of the storage 
systems regardless of the I/O management station plat- 
form, it is preferable that I/O management stations 112, 
120 are equipped with a Java-compliant web browser 
or other suitable Java run-time environment. Thus, as 
one skilled in the art will appreciate, if the management 
application programs for each of the storage systems 
are written in Java, the operating system environment 
of I/O management stations 112, 120 is irrelevant. That 
is, the Java applications can run in any environment, as 
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long as it is a Java-compliant environment. 
[0024] Referring now to Fig. 2, a more simplified ver- 
sion of a management system framework 200 is illus- 
trated. System 200 preferably comprises a network 202 

s with a plurality of managed devices 204-1 to 204- N con- 
nected thereto. In accordance with this particular em- 
bodiment of the present invention, managed devices 
204 may comprise storage systems or other suitable I/ 
O devices. In addition, an I/O management station 206 

10 preferably is connected to network 202 and configured 
to monitor, configure, and manage devices 204 on the 
network, 

[0025] As illustrated in Fig. 2, device 204-1 preferably 
includes control software which uses a management ap- 

15 plication interface program labeled "A." Similarly, devic- 
es 204-2 and 204-3 run control software which use a 
management interface application program labeled "B. 
B Finally, device 204-N preferably runs control software 
which uses a management interface application pro- 

20 gram labeled "X." In addition, system 200 preferably in- 
cludes a storage system 210 which comprises a man- 
agement applet repository 212 for holding a plurality of 
management interface application programs 214. As 
discussed briefly above, management interface appli- 
es cation programs 21 4 preferably are Java applets which 
can be run in any suitable Java run-time environment. 
[0026] In accordance with one aspect of the present 
invention, applet repository 212 may reside in internal 
storage of management station 206, or storage system 

30 210 may be an external storage system connected di- 
rectly to management station 206 via communication 
link 216. Communication link 216 may comprise any 
suitable communication link between a work station and 
a storage system such as PCI, SCSI, Fiber channel, 

35 USB, Firewire, or the like. Moreover, in accordance with 
an alternative embodiment of the present invention and 
as illustrated in Fig. 3, storage system 210 may be con- 
nected to network 202 via a suitable network connection 
218. In accordance with this aspect of the invention, 

40 management station 206 preferably communicates with 
storage system 210 through network 202; for example, 
along communication path 220. 
[0027] In accordance with one embodiment of the 
present invention, a user can direct management station 

45 206 to discover all the devices on the network which are 
to be managed by the management station and displays 
the devices on the management station display; i.e., a 
somewhat manual discovery process. In accordance 
with another embodiment of the present invention, dur- 

50 ing the start-up of management station 206, manage- 
ment station preferably runs an application 208 which 
automatically locates all devices 204 residing on net- 
work 202, and displays the list of devices on manage- 
ment station 206. Thus, when management station 206 

55 is directed to manage, monitor or configure a device 204 
on network 202, management station 206 preferably us- 
es information obtained during the locate process to 
match a particular device 204 with the appropriate man- 
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agement application 214 residing in repository 212. 
Once a match is made, management station 206 pref- 
erably retrieves the appropriate management applica- 
tion 214 and processes it on the station. As discussed 
in more detail below, the retrieved management appli- 
cation 214 then performs the necessary functionality to 
manage, monitor, and/or configure the particular device. 
Each management interface application program 214 
preferably is configured to communicate with and direct 
the controller, and in particular the control software, of 
the associated device 204. For example, management 
interface application program 214-A is specifically de- 
signed to monitor and communicate management and/ 
or configuration commands to device 204-1. Similarly, 
management interface application program 214-B is 
configured to monitor and communicate management 
and/or configuration commands to devices 204-2 and 
204-3, and management interface application program 
214-X is configured to monitor and communicate man- 
agement and/or configuration commands to device 
204-N. With this particular configuration, if at some later 
time a managed device 204 is updated to a new level of 
software that requires a different management interface 
program 214 to manage that device, or if a new man- 
aged device 204 of a different device type is added to 
the system, the software residing in the updated man- 
aged device or the new managed device will indicate 
the particular management interface application pro- 
gram 214 with which it is compatible. Thus, manage- 
ment station 206 will be able to determine which man- 
agement information application program 214 residing 
in repository 21 2 should launch for a given managed de- 
vice 204 on network 202. 

[0026] In accordance with a preferred embodiment of 
the present invention, when the control software of a 
managed device 204 is updated, for example to a new 
version, preferably a new management interface appli- 
cation program is added to the management interface 
application program repository to go along with the up- 
dated control software. 

[0029] In accordance with an alternative embodiment 
of the present invention, it may be preferable to only up- 
date small portions of the control software at any one 
time. For example, aspects of an array device that may 
be updated include individual object revision definitions 
for drive groups, drives, volumes, redundant controllers, 
storage systems, and the like. Thus, if only small revi- 
sions are made to the control software of a device 204, 
only small modifications need to be made to the man- 
agement interface application program 214. Alternative- 
ly, instead of changing the management interface appli- 
cation program 214, a new management interface ap- 
plication program 214 may be added to repository 212 
and may be run with the original interface application 
program, so that when the two management interface 
application programs are run together, they will be com- 
patible with the updated control software of the device. 
[0030] In accordance with another embodiment of the 
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present invention, instead of the management interface 
application programs residing in a separate repository 
as illustrated in Fig. 2, the I/O device itself may act as 
the repository for the management interface program for 

5 that device. Referring now to Fig. 4, system 400 is illus- 
trated in which the management interface application 
programs for a particular device actually reside on that 
device. In accordance with this embodiment of the 
present invention, system 400 preferably comprises a 

10 network 402, an I/O device 404, such as a storage sys- 
tem, and a management station 406. 
[0031] While device 404 may be any suitable I/O de- 
vice, for the purposes of this example, device 404 pref- 
erably is a RAID storage system. Accordingly, RAID 

15 storage system 404 comprises a RAID controller 406 
and a plurality of storage drives 408. Preferably, a man- 
agement interface application program for RAID device 
414 is stored in an area 410 on one or more of drives 
408. Thus, when management station 406 discovers 

20 RAI D device 404 on network 402, RAI D device 404 and 
in particular RAID controller 406, preferably passes the 
management interface application program from area 
410 on drives 408 to management station 406 across 
network 402. To facilitate this transfer, RAID controller 

25 406 preferably includes an application 412 which allows 
it to act as an embedded web server, giving it the ability 
to pass the management interface application program 
to management station 406 using a web server protocol, 
such as HTTP or the like. In this manner, RAID controller 

30 406 will act like any other web server on a network or 
on the Internet, passing HTML or Java byte code pro- 
grams to a work station having a web browser or other 
suitable Java run-time environment. 



[0032] Referring now to Fig. 5, software components 
of a management system 500 now will be discussed. In 
accordance with the embodiment of the present inven- 

40 tion illustrated in Fig. 5, system 500 preferably compris- 
es a network 502, a network attached I/O device 504, a 
proxy attached I/O device 506 attached to network 502 
via server 508, an I/O management station 51 0, and one 
or more third party management frameworks 512. While 

45 |/o devices 504 and 506 may comprise any suitable I/ 
O device on a network, for the purpose of this example, 
I/O devices 504 and 506 preferably comprise RAID stor- 
age systems. In addition, as illustrated in Fig. 5, other 
manageable devices 514 may be connected to server 

50 508. The other manageable devices 514 may comprise 
any suitable peripheral device, such as a host bus 
adapter, just a bunch of disks (JBOD), a SCSI device, 
or the like. 

[0033] The following discussion sets forth software el- 
55 ements which preferably reside within each of the de- 
vices on system 500. While system 500 is described 
herein as having a network attached RAID device 504, 
a proxy attached RAID device 506, and a server 508, 
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one skilled in the art will appreciate that other I/O device 
connections to network 502 may be used; for example, 
the other network attachment configurations illustrated 
in Fig. 1 and disclosed above. Thus, the present inven- 
tion is not limited to the configuration of Fig. 5. 

Management Station Software Components 

Discover-Monitor Applet 

[0034] As mentioned briefly above, management sta- 
tion 510 preferably comprises a Java compliant web 
browser, or alternatively, another suitable Java run-time 
compliant environment for running Java applet pro- 
grams. Preferably one of the application programs 
which management station 51 0 processes is a discover- 
monitor application or applet 516. Discover-monitor ap- 
plet 516 preferably is a Java applet which is stored in 
nonvolatile memory in management station 510, or in 
an applet repository residing on network 502. Prefera- 
bly, discover-monitor applet 516 can run under either a 
Java compliant web browser or under an operating sys- 
tem's Java run-time environment. 
[0035] Discover-monitor applet 516 performs, inter 
alia, the following functions: 

(1) Discovering managed devices on network 502 
and presenting them on the management station 
display; 

(2) Understanding and maintaining an association 
between the discovered managed devices and the 
specific management interface application program 
it requires; 

(3) Providing a user interface for invoking the man- 
agement interface application program for a partic- 
ular managed device, which in turn, presents a 
more detailed interface for managing the device; 
and 

(4) Listening for events from discovered devices 
and providing notifications, both on-screen visual, 
as well as via remote e-mail, of device state chang- 
es (e.g., "optimal, " "needs attention," or "unrespon- 
sive"). 

More detailed device notifications may be provided 
by the management interface application programs 
themselves. 

[0036] In accordance with the present invention, dis- 
cover-monitor applet 518 preferably is designed to allow 
coexistence of different management interface applica- 
tion programs for different types of devices, and within 
a device type, to permit coexistence of interface appli- 
cation programs at different versions of a device's man- 
agement interface software. Thus, new hardware can 
be introduced and old hardware can be phased out at a 
user's convenience without the risk of introducing man- 
agement incompatibilities. 
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Management interface Application Programs 

[0037] Management interface application programs 
518 preferably are Java applets which are device type 
5 and version specific program components. A particular 
management interface application program 518 knows 
how to manage an individual device of its associated 
type, and is responsible for presenting the detailed, de- 
vice-specific management operations to a user. In ac- 
cordance with a preferred embodiment of the present 
invention, discover-monitor applet 516 preferably lo- 
cates and loads the correct management interface ap- 
plication program 518 from storage, based on its knowl- 
edge of the managed device's management interface 
version. Generally, management interface application 
programs 518 display the current state, status and con- 
figuration of a device with which it is associated. In ad- 
dition, management interface application programs 518 
preferably include logic which allows a user to submit 
management and configuration commands to the man- 
aged device. A more detailed discussion of how man- 
agement interface application programs 518 operate is 
discussed below. 



[0038] In accordance with the present invention, the 
two main purposes of the server based software com- 
ponents are to: (1) Interface proxy attached controllers 

30 to the network so they can be managed by management 
station 510; and (2) Interface the managed devices to 
other industry standard management protocols and 
products. Preferably, the server based software compo- 
nents comprise a conversion application for converting 

3s rpc commands to a standard I/O read/write mecha- 
nism, and a DMI and/or SNMP interface application. 

RPC Conversion Agent 

40 [0039] RPC conversion agent 522 preferably com- 
prises a thin piece of server 508 resident software pref- 
erably written in Java and executing under an operating 
system's Java run-time environment. The purpose of 
RPC conversion agent 522 is to support remote proce- 
ss dure call (RPC) traffic between the management inter- 
face application program 518 running on management 
station 510 and a proxy attached storage controller 506 
(i.e., a storage controller that does not have its own net- 
work connection). As one skilled in the art will appreci- 
50 ate, a storage system connected to a server, for exam- 
ple via a PCI connection, does not communicate with 
the server using RPC, but using a standard I/O read/ 
write mechanism, such as a SCSI command interface. 
Thus, for the management application program 518 to 
55 communicate with controller 506, RPC conversion 
agent 522 preferably is configured to receive RPC com- 
mands from a management interface application pro- 
gram 518 and convert the RPC command to a protocol 
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which storage controller 506 will understand. In this par- 
ticular example, the RPC conversion agent 522 encap- 
sulates RPC messages within I/O write commands to 
send them to the direct-attached controller 506 via I/O 
path 524. Similarly, the RPC conversion agent 522 re- 
ceives RPC responses from controller 506 via I/O read 
commands, extracts the RPC responses from the I/O 
read commands and forwards the RPC responses to 
management application program 518. In accordance 
with a preferred embodiment of the present invention, 
the protocol for encapsulating RPC messages within 
read/write commands is a Universal Transport Mecha- 
nism (UTM), a protocol developed by LSI Logic Corpo- 
ration, located in Milpitas, California. RPC conversion 
agent 522 allows all management interface programs 
518 to be written the same, regardless of whether the 
storage controller-has a direct network connection or 
not. If the storage controller is not directly attached to 
the network, RPC conversion agent 522 performs the 
proper protocol conversion. 

Other Management Framework Agent 

[0040] Server 508 also preferably includes software 
to interface server 508 and other connected devices 
with other third party management frameworks or pro- 
tocols, such as desktop management interface (DMI), 
simple network management protocol (SNMP) and/or 
common information model (CIM). In accordance with 
this aspect of the present invention, server 508 prefer- 
ably includes a management framework agent 526, 
which comprises one or more applications which facili- 
tate communication between management stations like 
DMI, SNMP and/or CIM stations and devices connected 
to server 508. For example, in the case where DMI is 
used, agent 526 preferably comprises one or more DMI 
applications which enables devices to be managed with- 
in a DMI conformant management framework. The DMI 
architecture allows a device to deliver events to, re- 
spond to management information requests from, and 
even to be controlled by a DMI conformant management 
application. 

[0041] Server 508 also preferably supports the SNMP 
and CIM architectures. In accordance with this aspect 
of the present invention, agent 526 on server 508 pref- 
erably includes an SNMP framework application and/or 
a CIM framework application. In this manner, an SNMP 
or CIM management station can send requests to and 
receive event notifications from a device connected to 
server 508. DMI, SNMP and CIM interface agents are 
known in the art, and thus, will not be described further 
herein. 

Controller-Based Software Components 

[0042] Device controllers 504 and 506 both preferably 
include a management protocol 528 and a RAID engine 
530. In addition, network attached controller 504 prefer- 



ably includes an RPC-to-intemal-messaging compo- 
nent 532 and a controller embedded DMI, SNMP and/ 
or CIM service provider 534. In addition, proxy attached 
controller 506 preferably includes a UTM-to-internal 
s messaging component 536. 

Management Protocol 

[0043] The architecture of the present invention is 

10 centered around an object model of the managed de- 
vices, which is the basis for communication between 
management station 510, and in particular management 
interface application program 528, and the devices 
(504, 506). The object model preferably is the actual 

is physical and logical configuration of the device. In the 
storage array case, the object model of the storage array 
is handled by the controller via a management protocol 
528. An example of a suitable management protocol is 
LSI Logic's SYMbol (symbios browser-oriented lan- 

20 guage) protocol. Management protocol 528 preferably 
receives high-level requests from management inter- 
face application (or applet) program 518 expressed in 
terms of the device object model, interprets the re- 
quests, carries out the requests by interacting with RAID 

25 engine 530 and then responds back to the management 
interface applet 518 in terms of the object model. The 
object model also defines events that originate with the 
managed device and flow to the management station 
510; this event propagation is also the responsibility of 

30 management protocol 528. 

RAID Engine 

[0044] RAID engine 530 is the part of the storage con- 

35 trailer firmware that is responsible for the core RAID im- 
plementation, independent of the host and drive inter- 
faces with which it interacts. RAID engine 530 preferably 
comprises a performance critical RAID read/write/cach- 
ing component and a less-performance-critical configu- 

40 ration and management component. The configuration 
and management component, which is the focus and 
the content of the management architecture of the 
present invention, preferably exhibits three main types 
of behavior: (1) carrying out management related tasks 

45 when directed to do so by the management station 51 0 
and more specifically, management interface applica- 
tion program 51 8; (2) performing certain tasks automat- 
ically, either when necessary, or on a regular schedule 
(e.g., error and event logging and parity assurance); and 

50 (3) initiating notifications of important events, which are 
then propagated outside of the controller over network 
502, either directly or via UTM in the proxy attached 
case. 

55 UTM-tO'lnternal-Messaging 

[0045] As discussed briefly above, proxy attached 
controller 506 preferably includes a UTM-to-internal- 
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messaging component 536. UTM-to-internal messag- 
ing component 536 preferably is part of the controller 
firmware for proxy attached controller 506, and is re- 
sponsible for providing management protocol packet 
transport over the block read/write path between server 
508 and controller 506. This communication preferably 
is bi-directional, allowing commands to be transported 
into and responses to be transported out of controller 
506. 

[0046] As discussed above, management interface 
application programs 518 preferably communicate us- 
ing the RPC protocol. In the proxy attached controller 
506 case, controller 506 communicates with server 508 
using UTM, so RPC conversion agent 522 in server 508 
converts the RPC commands to the UTM format before 
communicating with controller 506. Upon receiving the 
UTM packets, UTM-to-internal-messaging component 
536 preferably converts the UTM packets to packets 
and commands which can be understood by manage- 
ment protocol 528. Thus, UTM-to-internal-messaging 
component 536 in essence comprises a UTM interface 
for controlling communications between server 508 and 
controller 506, and an internal controller mechanism for 
controlling command and event notification dispatch to 
and from management protocol server 528. 
[0047] While a preferred embodiment of the present 
invention is described herein as using UTM to commu- 
nicate between server 508 and device 506, one skilled 
in the art will appreciate that other I/O read/write mech- 
anisms, such as a SCSI command interface, may be 
used. Therefore, the present invention is not limited to 
the UTM embodiment. 

RPC-to-lntemal-Messaging 

[0048] As mentioned briefly above, network attached 
controller 504 preferably includes an RPC-to-internal- 
messaging component 532. RPC-to-intemal-messag- 
ing component 532 preferably is part of the network at- 
tached controller firmware which transports RPC trans- 
actions between the controller network port and the 
management protocol server 530. Preferably, packets 
crossing the controller network port interface 538 con- 
form to standard RPC commands. At RPC-to-internal- 
messaging component 532, the RPC commands are 
converted to the management protocol format 528. 
Thus, the combination of the RPC conversion agent 522 
in server 508 and the UTM-to-internal messaging com- 
ponent 536 in proxy attached controller 506 is the func- 
tional equivalent of the RPC-to-internal-messaging 
component 532 of network attachment 504. That is, 
RPC conversion agent 522 and UTM-to-internal-mes- 
saging component 526 effectively convert the RPC com- 
mands from management interface application 518 to 
the management protocol 528 format. However, with the 
proxy attached controller 506, an additional protocol, 
preferably UTM between server 508 and controller 506 
is used. 
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Controller Embedded DMl, SNMP and/or CIM Service 
Provider. 

[0049] Embedded service provider 534 in network at- 
5 tached controller 504 preferably is one or more software 
elements defined under the DM1 , SNMP and/or CI M ar- 
chitectures. The embedded service provider 534 is con- 
figured to mediate between managed objects, such as 
controller 504, and a DMl, SNMP or CIM management 
10 application. By adding embedded service provider 534 
within the network attached controller 504, controller 
504 can interface with a DMl, SNMP or CIM manage- 
ment application on network 502. DMl, SNMP and CIM 
management applications may reside within a separate 
15 management station, such as management station 51 2, 
or the DMl, SNMP and CIM management applications 
may be applications or applets 520 which executes in 
the Java run-time environment of management station 
510. 

20 

User Interface 

[0050] As discussed briefly above, a user preferably 
interfaces with the management station 510 via a dis- 

25 cover-monitor application program 51 6 and a manage- 
ment interface application program 518 for each of the 
devices on the network. Preferably, both the discover- 
monitor application 516 and each of the management 
interface application programs 518 are Java programs 

30 or applets which run in a Java run-time environment. 

Dlscover-monltor Application 

[0051] Referring now to Fig. 6, a representation of a 

35 discover-monitor application screen 600 is illustrated. 
Preferably, discover monitor application screen 600 in- 
cludes a management domain window 602, a detailed 
information window 604, a status indicator 606 and a 
status line 608. 

40 [0052] In accordance with a preferred embodiment of 
the present invention, management domain window 602 
presents a tree structured view of the complete man- 
agement domain. Lower level nodes 61 0, 61 2 in the tree 
structure represent actual physical hardware devices 

45 such as servers, arrays, and other I/O devices. For ex- 
ample, as illustrated in Fig. 6, lower level node or server 
612-1 includes two storage arrays 610-1 and 610-2 at- 
tached thereto. Similarly, lower level node or server 
612-2 includes a storage array 610-3 attached thereto. 

50 The higher level nodes in the tree represent the location 
of the hardware devices. For example, in the illustrated 
embodiment, the management domain is divided into 
two regions: a central region 618-1 and a southeast re- 
gion 618-2. Within central region 618-1, the domain is 

55 further broken into states 616, for example, Kansas 
616-1 and Colorado 616-2. From there, the domain is 
further broken down into plant locations 614, for exam- 
ple, in Colorado 616-2, the illustrated company has lo- 
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cations in Colorado Springs 614-2 and Fort Collins 
614-3. The management domain shows the servers, 
storage arrays and other devices which exist on the net- 
works ot those locations. 

[0053] Detailed information window 604 preferably 
presents the detailed properties for each device in the 
management domain, based upon the particular node a 
user selects. Individual device nodes 61 0, 61 2 or a high- 
er level location nodes 614, 616, 618 may be selected. 
When a location is selected, the detailed information 
window preferably includes an entry for each device in 
the subtree rooted at the selected location. When a spe- 
cific device node is selected, detailed information win- 
dow 604 displays certain device specific attributes of the 
selected node. In addition, by double-clicking or select- 
ing a specific device node, the device's associated man- 
agement interface application program is launched. 
[0054] Status indicator 606 preferably includes a high 
level indication of whether or not any of the devices in 
the management domain have problems that require at- 
tention. If all devices are in working order, the status in- 
dicator preferably will indicate "optimal"; if there is a 
problem somewhere in the management domain, the 
status indicator 606 preferably will show that one or 
more devices require attention. Preferably the devices 
that have a problem will be indicated in the management 
domain window 602 by a highlighted color of that device, 
or an appearance change of the device icon. Finally, sta- 
tus line 608 preferably is an area for short pieces of con- 
text-sensitive information which the discover-monitor 
application program may wish to display. 
[0055] While the discover-monitor application screen 
illustrated in Fig. 6 and disclosed herein presents infor- 
mation in a certain way and includes specific informa- 
tion, one skilled in the art will appreciate that the discov- 
er-monitor application screen may be designed and 
configured in any way. For example, the discover-mon- 
itor application screen may show additional information, 
or certain information that is displayed in the discover- 
monitor application screen of Fig. 6 may be eliminated. 
In addition, the information may be presented in a dif- 
ferent way. Thus, the present invention is not limited to 
the specific embodiment of the discover-monitor appli- 
cation screen illustrated in Fig. 6. 

Management Interface Application 

[0056] Referring now to Fig. 7, screen display 700 of 
a management interface application or applet program 
is illustrated. When a user selects and opens a particular 
device from the discover-monitor application screen, the 
management interface application program for that de- 
vice is loaded into the management station, and a 
screen similar to screen 700 preferably is displayed. 
Display 700 preferably includes a logical view window 
702 and a physical view window 704. 
[0057] Logical view window 702 illustrates the logical 
composition and properties of the selected device (e.g., 
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storage array). The logical objects of the storage array 
are organized into a tree structure to make their interre- 
lationships apparent. Screen 700 illustrates an example 
of a typical set of logical objects, including volume 
s groups 706, volumes 708, free capacity regions 710, 
and unassigned capacity 712. 

[0058] Physical view window 704 preferably illus- 
trates a view of actual hardware components in a par- 
ticular device or storage array, e.g., controllers, drives, 

10 drive trays, disks, etc. Preferably, the physical view of 
the storage array displayed in physical view window 704 
is an accurate graphical representation of the actual 
storage array device on the system. In this manner, the 
user can tell what the device looks like without being 

15 within visual range of the device. In the physical view 
704, components in need of repair or replacement pref- 
erably will be distinguished by color and/or appearance 
changes. In addition, color or other visual differences 
may be used to indicate different roles or states of disk 

20 drives (i.e., assigned, unassigned, hot, spare, etc.). As 
with discover-monitor output screen 600, management 
interface application screen 700 is not limited to the em- 
bodiment shown in Fig. 7. Additional information may 
be added, deleted, or the actual presentation of the in- 

25 formation may vary. Thus, the present invention is not 
limited to the illustrated embodiment. 

System Functional ity 

30 Discover Monitor Applet Startup 

[0059] Referring now to Fig. 8, a flow diagram 800 is 
shown illustrating a start-up procedure for a discover- 
monitor application and a management interface appli- 
35 cation. Flow diagram 800 includes client or manage- 
ment station elements 802, server elements 804, device 
controller elements 806, and web server elements 808. 
In accordance with a preferred embodiment of the 
present invention, when server 804 starts-up, for exam- 
40 p| 0) during morning start-up, an RPC-to-UTM Agent 81 0 
automatically starts running on server 804 (step 8A). 
Next, RPC-to-UTM Agent 810 preferably queries a da- 
tabase 812 on server 804 to determine which devices 
connected to server 804 (in this particular example, stor- 
es age controllers) require RPC-to-UTM transport services 
(step 8B). Preferably, database 812 stores a record for 
each device connected to server 804. The device 
records in database 812 preferably include a field which 
indicates whether the device requires RPC-to-UTM 
50 transport services. For each device requiring RPC-to- 
UTM transport services, RPC-to-UTM agent 810, starts 
an RPC connection listener 814 (step 8C). While the il- 
lustrated embodiment shows only one RPC connection 
listener 81 4, other connection listeners may be running 
55 on server 804. 

[0060] When a user wishes to begin the device man- 
agement process, the user preferably starts-up man- 
agement station 802, which starts a browser session 
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816 (step 8D). During the browser start-up process, the 
user preferably supplies the URL of the process discov- 
er-monitor applet to be run. Browser 816 uses the URL 
to address an HTML page on web server 808. Alterna- 
tively, the URL may be stored in the browser or on the 
machine running the browser. Browser 816 then con- 
tacts web server 808's HTTP server 818 and asks that 
the discover monitor applet (DMA) be transferred to 
browser 816 (step BE). In accordance with a preferred 
embodiment of the invention, HTTP server 81 8 retrieves 
the DMA program from an applet repository 820 on web 
server 808 (step 8F) and sends the DMA program to 
browser 816 (step 8G). 

[0061] In accordance with an alternative embodiment 
of the present invention, instead of HTTP server 818 
sending the actual DMA program to browser 816, HTTP 
server 818 may send an HTML page to browser 816, 
notifying the browser of the location of the DMA pro- 
gram. Then, browser 816 preferably retrieves the DMA 
program from the specified location. In the illustrated 
embodiment, the location of the discover-monitor applet 
happens to be on web server 808. However, as dis- 
cussed previously, the discover-monitor applet may re- 
side in a repository stored on one or more storage sys- 
tems residing on the network. In addition, while the start- 
up process discussed herein refers to an HTTP server 
sending HTML pages to browser 81 6, other start-up pro- 
cedure may occur. For example, communication proto- 
cols and languages other then HTTP and HTML may be 
used. Finally, while the illustrated embodiment shows 
web server 808 being separate from management sta- 
tion 802, the present invention may be configured so 
that web server 808 is part of management station 802. 
[0062] After browser 81 8 retrieves the discover-mon- 
itor applet program from applet repository 820, the dis- 
cover-monitor applet 822 is invoked according to the 
standard browser of Java run-time environment protocol 
for starting an applet (step 8H). 
[0063] In accordance with one embodiment of the 
present invention, a user may utilize DMA 822 to dis- 
cover each managed device connected to the network. 
In accordance with this particular embodiment of the in- 
vention, the user preferably enters the device into DMA 
822, and DMA 822 then starts a monitor thread 824 for 
the entered device. Preferably, there will be a monitor 
thread 824 for each device selected by the user. 
[0064] In accordance with an alternative embodiment 
of the present invention, discover-monitor applet 822 
may be configured to automatically discover all the de- 
vices on the network. DMA 822 discovers all direct net- 
work attached devices and all servers on the network. 
Upon locating a server, discover-monitor applet 822 re- 
quests from the server a list of all storage controllers or 
devices it has associated with it. After locating all the 
devices on the network to be managed, DMA 822 starts 
a monitor thread 824 for each device (step 81). 
[0065] After initializing a monitor thread 824 for each 
discovered device, the monitor threads 824 preferably 
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initiate a connection to their associated devices 806 by 
connecting to the RPC connection listeners 814 (step 
8J). As discussed above, RPC connection listeners 
preferably are started on one or more servers 804 for 

5 each device 806 connected to the servers and being 
monitored by the management station. Once monitor 
threads 824 are connected to RPC connection listener 
814, RPC connection listener then creates an RPC 
agent thread 826 for servicing the connection (step 8K). 

10 [0066] In each device controller 806, a management 
protocol server 828 is listening for management protocol 
requests. Each management protocol server 828 is que- 
ried (via an RPC agent thread 826) for its associated 
device properties (step 8L). Using the information from 

15 this step 8L, RPC agent thread 826 notifies monitor 
thread 824 of the device properties of the associated 
device 806 (step 8M). In turn, monitor thread 824 then 
updates DMA 822 with the device properties (step 8N). 
Upon receiving the device properties, DMA 822 builds 

20 a device connection table, which gives, for each device, 
a list of connections into the device. The connection-to- 
device map may be one-to-one, or many-to-one. In ad- 
dition, the device connection table may include informa- 
tion about which management application program is 

25 associated with each device. 

[0067] Finally, with all storage arrays discovered, and 
all communication links set up, discover-monitor applet 
822 displays the discovered devices on a display screen 
from which device specific storage management appli- 

30 cations may now be launched. 

[0068] In addition to obtaining device properties from 
devices 806, monitor thread 824, and RPC agent 
threads 826 for each device may be configured to mon- 
itor each device 806 for configuration changes or other 

35 device events. In accordance with this aspect of the 
present invention, discover-monitor applet 822 pre- 
pares for event listening by starting a management pro- 
tocol "event listener" thread, which detects events from 
the device via the "Hanging AEN" protocol. Monitor 

40 thread 824 on management station 802 preferably acts 
as the event listener thread, and starts the hanging AEN 
event in much the same way as the other RPC agent 
threads are started. That is, event listener thread or 
monitor thread 824 in management station 802 estab- 

45 lishes a connection to the RPC connection listener 81 4 
in server 804 (step 8J), which initiates an RPC agent 
thread 826 (step 8K). For device monitoring, the agent 
thread 826 preferably is configured for hanging AEN lis- 
tening, and thus, initiates a hanging AEN listen primitive 

50 on controller 806, and in particular management proto- 
col server 828. 

[0069] In accordance with a preferred embodiment of 
the present invention, the hanging AEN listening 
threads exist until an event occurs on a device 806. For 
55 example, if the configuration of device 806 changes for 
any reason, the hanging AEN agent thread 826 will de- 
tect the change and notify monitor thread 824 of the 
change (step 8M). Monitor thread 824 then will update 
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the device characteristics of device 806 on DMA 822 
which then displays the configuration change status on 
a display associated with DMA 822 (step BN). After the 
update, DMA 822 then will start another hanging AEN 
thread for that device. A more detailed discussion the 
event notification process is discussed below in the sec- 
tion entitled Event Reporting. 

Management Interface Application Start-up 

[0070] Still referring to Fig. 8, flow diagram 800 also 
illustrates the start-up procedures for a management in- 
terface application. As discussed previously, discover- 
monitor application or applet 822 preferably discovers 
and lists all devices and/or storage systems connected 
on a network. For this particular example, the devices 
will be storage system devices. To start a management 
interface application for any of the storage systems on 
the network, the user preferably double-clicks on one of 
the storage systems when viewing it in the discover- 
monitor application (DMA) screen (step 80). Next, DMA 
822 preferably receives device property information 
about the selected storage system device from a device 
property storage area (not shown). 
[0071] Included in the device properties is the storage 
system's management interface version (i.e., the man- 
agement application program associated with that de- 
vice). Next, DMA 822 retrieves from applet repository 
820 residing on web server 808 or some other location 
the management interface application program version 
specified in the device properties for the selected device 
(steps 8P-8R). Preferably, the management interface 
application program is a Java applet which is loaded into 
and run on management station 802 using a web brows- 
er or other suitable Java run-time environment. After re- 
trieving the management interface application program 
from repository 820, DMA 822 then launches the man- 
agement interface application 830 for the selected stor- 
age system (step 8S). 

[0072] Once started, management interface applica- 
tion 830 preferably starts a management interface ap- 
plication RPC handler 832, which controls the commu- 
nication of RPC commands between management ap- 
plication 830 and server 804. Management interface ap- 
plication RPC handler 832 then starts an RPC agent 
thread 834 on server 804, which facilitates communica- 
tion between management interface application 830 
and device 806 (step 8Y). Next, using RPC agent thread 
834, management interface application 830 retrieves 
the selected storage system's internal object organiza- 
tion residing on controller 806 of the storage system 
(step 8Z). With this information, management interface 
application 830 knows how to connect to management 
protocol server 828 running in the storage system con- 
troller 806. The object graph received from storage sys- 
tem controller 806 identifies the objects comprising the 
storage array and their interrelationships. For each ob- 
ject in the object graph, management interface applica- 
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tion 830 preferably initiates a proxy object to represent 
the storage system's object graph on management sta- 
tion 802. That is, management interface application 820 
stores a copy of the storage system's object graph on 
5 management station 802, so it can access and display 
the object graph when necessary. After retrieving the 
storage systems organization and configuration, man- 
agement interface application 830 displays the storage 
system's configuration on a display screen. 
10 [0073] When a user wants to change the configuration 
of one of the devices on the network, for example device 
806, the user instructs the management interface appli- 
cation 830 to initiate the change (step 8W). Manage- 
ment interface application 830 then passes the change 
is request to RPC handler 832 (step X), which issues the 
request to RPC agent thread 834 as an RPC command 
(step 8Y). RPC agent thread then encapsulates the 
RPC change request into a UTM packet and transmits 
the change to the controller of device 806 (step Z). De- 
20 vice 806 preferably processes the change request and 
sends a status update information back to management 
interface application 830. More detailed discussions of 
how configuration change requests are processed are 
discussed below in the sections entitled Volume Crea- 
ks tion, Configuration Replication, and Long-Term Opera- 
tions. 

[0074] In accordance with the embodiment of the 
present invention described herein, preferably server 
804 includes demultiplexing software for routing man- 

30 agement commands to the proper device 806 attached 
to server 804. Because devices 806 are attached to the 
network via server 804, management commands direct- 
ed to devices 806 are sent to the IP address of server 
804, hot the IP address of the devices 806. Thus, server 

35 804 includes intelligence (preferably built in software) 
for directing the management commands to the proper 
RPC Connection Listener 814 and/or RPC Agent 
Threads 826,834 associated with the proper device 806. 
[0075] In accordance with yet another embodiment of 

40 the present invention, instead of server 804 having de- 
multiplexing software for directing commands to the 
proper device 806, server 804 may include a device 
mapper for allocating I P addresses to the connected de- 
vices 806. For example, in accordance with one partic- 

45 ular embodiment of the invention which uses a device 
mapper, the device mapper, which preferably runs on 
server 804, locates all devices 806 connected to server 
804. For each device 806 found, the device mapper al- 
locates a dedicated TCP/IP port to it and saves the de- 

so vice-to-port association in a device-to-port map. When 
discover monitor applet 822 discovers all the devices 
806 on the network, the device-to-port association is 
provided to DMA 822 from the device-to-port map locat- 
ed on server 804. The DMA 822 then uses the device- 

55 to-port association to send management commands to 
a particular device 806 connected to server 804. 
[0076] Fig. 8 illustrates how discover-monitor applet 
822 locates and communicates with devices (e.g., stor- 
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age controllers) proxy connected to a network through 
a server. While not discussed herein, a similar proce- 
dure preferably is used to locate and communicate with 
devices direct attached to the network. However, as dis- 
cussed above, the RPC-to-UTM agent server 810 is not 
needed in the network attached case because the net- 
work attached controller includes firmware for receiving 
and translating RPC commands directly. 

Volume Creation 

[0077] Referring now to Fig. 9, a flow diagram 900 is 
shown illustrating the steps of creating a new volume on 
a storage system. If a user wishes to create a new vol- 
ume on a storage system, the user preferably selects 
the new volume option shown on the display screen 
(step 9A). Next, the management interface application 
902 fetches a list of "volume candidates" from storage 
system controller 904. The storage system controller re- 
ports a list of volumes that can be created, given the 
current drive group configuration of the storage system 
(see step 9B). Management interface application 902 
then displays the new volume candidates on display 906 
to the user as "volume creation options" (step 9C). Next, 
the user picks and possibly customizes one of the vol- 
ume creation options (step 9D). This "new volume spec- 
ification" is supplied as an input to the management in- 
terface application 902. The management interface ap- 
plication 902 converts the new volume specification in- 
put by the user into a "create volume" command which 
can be understood by the storage systems controller 
904 (step 9E). Controller 904 creates a new volume, and 
records that event in an array event log 908 (step 9F). 
As soon as the new volume is in a "committed", usable 
state, the "create volume" command returns to manage- 
ment interface application 902 (step 9G). The controller 
then reports a "configuration changed" event to listening 
clients (steps 9H and 91). As flow diagram 900 illus- 
trates, more than one management client may exist on 
the network. In the illustrated embodiment, there are two 
management clients, 902 and 910. However, any 
number of management clients may exist on the net- 
work. 

[0078] When each of the clients 902, 910 receive the 
"configuration changed" event, clients 902, 910 prefer- 
ably update their respective storage system screen dis- 
plays 906, 912, showing that the new volume is in a state 
of "optimal-initializing" since, although usable, it does 
not have good parity (step 9J and 9K). Controller 904 
then initiates parity initialization on the new volume. 
Since the new volume is reported as being in the "ini- 
tializing" state, management clients 902, 910 display a 
progress bar for the parity initialization task on display 
devices 906, 912 (steps 9N and 90). Clients 902 and 
910 periodically request progress data from controller 
904 and use that information to update the displayed 
progress bar (steps 9P and 9Q). When the parity initial- 
ization task completes, controller 904 transmits a "con- 



figuration changed" event to clients 902, 910, indicating 
that the new volume is in the "optimal" state (steps 9R 
and 9S). Clients 902 and 910 then indicate on display 
devices 906 and 912, respectively, that the parity initial- 
s ization task is complete (steps 9T and 9U). Management 
clients 902, 910 may display the task complete status 
in a variety of ways, including advancing the progress 
bar to 100%, dismissing the progress bar or displaying 
a message that the task is complete. 

10 

Configuration Replication 

[0079] Referring now to Fig. 10, a flow diagram 1000 
is shown illustrating the process of replicating a storage 
is system configuration from one storage system to anoth- 
er. To replicate the configuration of one storage system 
to another, a user preferably selects a source storage 
array and invokes a management interface application 
101 2 for that system (step 10A). Preferably, the user us- 
20 es the discover-monitor applet 1010 running on man- 
agement station 1 002 to invoke the management inter- 
face application 1012. Next, the user selects a destina- 
tion storage array which is to receive the source storage 
array's configuration, and invokes a management infor- 
ms mation application 101 4 for that array (step 10B). Again, 
the user preferably uses the discover-monitor applet 
1010 in management station 1002 to invoke the desti- 
nation storage system's management interface applica- 
tion 1014. Next, the source storage system's manage- 
30 ment interface application 1012 preferably fetches the 
device configuration description for the source storage 
system from storage system 1004, and in particular, 
controller 1016 (step 10C), and writes it to file 1018 (step 
10D). 

35 [0080] In the next step, the destination storage sys- 
tem's management interface application 1014 is direct- 
ed to "apply" the saved configuration description to the 
destination storage system 1006 (step 10E). In accord- 
ance with this aspect of the invention, destination stor- 

40 age system management interface application 1014 
preferably displays a confirmation dialogue on display 
1020 so that the user can confirm the application of the 
configuration description (step 10F). 
[0081] To update destination storage system 1006 

45 with the source storage system's configuration, the des- 
tination system 1006 first should be synchronized with 
the source storage system 1004 with respect to 
firmware sets. Thus, management interface application 
1014 preferably retrieves the firmware that it needs for 

so the destination device 1006 from a firmware repository 
1022 residing on a web server 1008 or other suitable 
storage location (step 10H). The selected firmware is 
then loaded into the destination device 1 006 and, in par- 
ticular, controller 1024 (step 101). Next, management in- 

55 terface application 1014 passes the rest of the configu- 
ration description to controller 1024 on destination de- 
vice 1006 (step 10J). Upon receiving the configuration 
description, the destination device 1006 then reconfig- 
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ures itself, issuing "config change" events and "new 
task" events as appropriate (step 10K). 

Mass Operations 

[0082] As one skilled in the art will appreciate, it may 
be preferably to perform a specific management task on 
a plurality of systems on a network. For example, in- 
stead of performing a configuration replication on a sin- 
gle system as discussed above with reference to Fig. 
10, it may be desirable to perform the configuration rep- 
lication on a plurality of devices at the same time. Thus, 
it is desirable to have an operation which can perform 
management functions on a plurality of devices at the 
same time. In accordance with the present invention, 
any particular management command can be per- 
formed as a mass operation on a plurality of devices. 
However, for illustration purposes, the mass operation 
model will be described herein as a mass configuration 
replication. However, the present invention is not limited 
to the specific example. 

[0083] Referring now to Fig. 1 1 , a flow diagram 1 1 00 
of a mass configuration replication operation is shown. 
To initiate the mass configuration replication operation, 
a user 1110 preferably utilizes a discover-monitor appli- 
cation 1112 running on management station 11 02 to se- 
lect a source storage system 1104 and launch a man- 
agement interface application 1114 for the selected 
source storage system 1 1 04 (steps 1 1 A and 1 1 B). Next, 
user 1110 preferably selects a "generate config file" or 
other similar task from management interface applica- 
tions 11 14 task menu (step 11C). Management interface 
application 1114 then will process the "generate config 
file" task by requesting and obtaining the configuration 
description of the source storage system 1104 from its 
controller 1116 (step 1 1 D). Management interface appli- 
cation 1114 will then save the configuration description 
from the source storage system 1 1 04 into a storage area 
1118 (step 11 E). In accordance with one particular em- 
bodiment of the invention, user 1110 may edit the con- 
figuration description in storage area 1118 (step 1 IF). 
The editing function may be performed using discover- 
monitor applet 1112, management interface application 
1114, or another suitable editing application program 
which may reside on management station 1102. 
[0084] After the configuration description is finalized, 
user 1110 preferably selects the mass operation func- 
tion on discover-monitor applet 1112 (step 1 1 G). Discov- 
er-monitor applet 1112 retrieves the configuration de- 
scription from storage area 1118 (step 11H), and then 
loads from a second storage area 1120 a list of storage 
systems on the network which may be destination sys- 
tems to receive the mass configuration operation (step 
111). Discover-monitor applet 1112 then displays the list 
of storage systems on the network on a display device 
1122 (step 11 J). User 1110 preferably selects the stor- 
age systems which it would like updated with the source 
configuration description (step 1 1 K), and discover-mon- 



26 

itor applet 1112 then launches management interface 
applications 1124-1 to 1124-N for each of the selected 
storage systems (step 11 L). As with the configuration 
application process illustrated in Fig. 10 and discussed 

s above, each of the management interface applications 
1124 retrieves a firmware set from firmware repository 
1128 in server 1108 or other suitable storage location 
(step 1 1 M), and applies the controller firmware set to the 
controller 1126 of the appropriate destination device 

10 1106 (step 11N). For example, management interface 
application 1124-1 preferably retrieves a firmware set 
and applies it to controller 1126-1 of destination storage 
system 1106-1. Similarly, management interface appli- 
cation 1124-2 retrieves a firmware set and applies it to 

15 controller 1126-2 of destination device 1106-2, and so 
on. 

[0085] After each of the controller firmware sets have 
been updated, each of the management interface appli- 
cations 1124 send the configuration description to the 

20 destination devices 1106 and their controllers 1126 
(step 110). Controllers 1126 receive the configuration 
description, perform the configuration change operation 
(s) and then pass back "configuration" and "new task" 
events to the management interface applications 1124 

25 (step 11 P). 

[0086] As one skilled in the art will appreciate, before 
a configuration change is implemented, error checking 
typically is performed to determine whether the destina- 
tion device is compatible with the configuration descrip- 

30 tion. That is, whether the particular hardware of the des- 
tination storage system can accept and implement the 
configuration set forth in the configuration description. 
In addition, the software in the controller should be 
checked to determine if it can perform the functions re- 

35 quired to implement the configuration update. In accord- 
ance with this particular aspect of the invention, an error 
checking routine 1200 as illustrated in Fig. 12 may be 
used. Error checking routine 1200 preferably comprises 
a hardware check module 1202 which retrieves hard- 

40 ware configuration restraints from the configuration de- 
scription 1204 (step 12A). In addition, hardware check 
module 1202 preferably retrieves the target or destina- 
tion hardware configuration 1206 from the destination 
hardware device (step 12B). Hardware check module 

45 1202 then performs a check to determine whether the 
hardware target configuration is compatible with the 
configuration restraints from configuration description 
1 204. That is, hardware check module 1 202 determines 
whether the target or destination hardware device can 

so be configured according to the hardware configuration 
restraints. If not, hardware check module 1202 displays 
an error message on a display 1 208 (step 1 2C). If there 
is no error, the error check routine moves on to software 
check module 1210 (step 12D). 

55 [0087] Software check module 1210 preferably re- 
trieves the configuration specification 1212 from config- 
uration description 1204 (step 12E), as well as the des- 
tination device's software version specific rules 1214 
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(step 12F). The destination device's software version 
specific rules preferably set forth the functions which the 
destination device's software can perform. If the de- 
vice's software version cannot perform a particular con- 
figuration update, software check routine 1210 displays 
an error on display 1 208 (step 1 2G). If the software can 
perform the configuration change, the error routine 
moves on to the apply configuration module 1216 (step 
12H). Apply configuration module 1216 preferably re- 
trieves the configuration specification 1212 from de- 
scription 1204 (step 121) and uses it to perform the con- 
figuration change (step 12J). Preferably, the apply con- 
figuration module 1216 comprises the discover monitor 
applet, management interface applications, and other 
management application programs discussed above 
with reference to Figs. 9, 10 and 11 above. 
[0088] While the error routine set forth in flow diagram 
1200 is described in the context of a configuration rep- 
lication example, one skilled in the art will appreciate 
that the error routine or a similar error routine may be 
performed on any mass operation management func- 
tion. In addition, the error routine set forth in Fig. 1 2 and 
described herein may be performed on other non-mass 
operation management functions, such as the volume 
creation example illustrated in Fig. 9 and the configura- 
tion replication example illustrated in Fig. 10. 

Event Reporting 

[0089] Referring now to Fig. 1 3, a flow diagram 1 300 
is shown illustrating the process of a managed device 
reporting events to a management station. To begin an 
event reporting/monitoring session of a proxy attached 
storage system or device, a management station (not 
shown) preferably sends a "connect" command to serv- 
er 1302 and more specifically to RPC-to-UTM agent 
server 1306 (step 13A). After receiving the "connect" 
command, RPC-to-UTM agent server 1 306 preferably 
creates an RPC-to-UTM agent thread 1308 to service 
the connection (step 13B). In accordance with a pre- 
ferred embodiment of the present invention, the RPC- 
to-UTM agent thread preferably is a dedicated hanging 
asynchronous event notification (AEN) listener. 
[0090] Once the RPC-to-UTM agent thread is started, 
the management station preferably issues an RPC com- 
mand, such as a "GetConfigChangelnfo" command or 
the like to the RPC-to-UTM agent thread 1308 (step 
13C). RPC-to-UTM agent thread 1308 converts the 
"GetConfigChangelnfo" RPC packet or other suitable 
command packet into a UTM buffer and forwards it on 
to storage system 1304 as a UTM transaction (step 
13D). Preferably, storage system 1304-includes a con- 
troller 1310 and a UTM-to-internal-messaging compo- 
nent 1 31 2. As one skilled in the art will appreciate, UTM- 
to-internal-messaging component may be a process for 
run within controller 1310. UTM-to-internal-messaging 
component 1312 preferably receives the "GetCon- 
figChangelnfo" command via UTM and starts a hanging 
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AEN event 1314 (step 13E). 

[0091] The hanging AEN event is an event 1314 
which waits for an event notification from the storage 
system before any status is returned to server 1 302, and 

5 the management station. When an event within storage 
system 1304 occurs, controller 1310 delivers an event 
notification to UTM-to-internal-messaging component 
1 31 2 (step 1 3F). When the event notification is received, 
UTM-to-internal-messaging component 1312 config- 

10 ures the event notification information into a suitable 
UTM packet and retrieves the "GetConfigChangelnfo" 
call from its hanging status (step 1 3G). UTM-to-internal- 
messaging component 1 312 then returns the event no- 
tification information as a UTM packet or buffer 1316 to 

15 the RPC-to-UTM agent 1308 (step 13H). The AEN lis- 
tener in RPC-to-UTM agent 1 308 extracts the event in- 
formation from the UTM buffer 1 31 6 (step 1 31 ), and then 
writes the event information to a RPC message buffer 
1318 (step 13J). RPC-to-UTM agent 1308 then returns 

20 the "GetConfigChangelnfo" RPC function to the man- 
agement station along with the event notification infor- 
mation in buffer 1318 (step 13K). After processing the 
event notification information, the management station 
sends another "GetConfigChangelnfo" function call in 

25 order to start the event notification process again (step 
13L). Again, the RPC-to-UTM agent 1308 then sends 
the "GetConfigChangelnfo" command in UTM format to 
UTM-to-intemal messaging component 1 31 2 in storage 
device 1304 (step 13M). The hanging AEN event will 

30 then initiate until another notification occurs. 

[0092] The event notification example illustrated in 
Fig. 13 and disclosed herein refers to a "GetCon- 
figChangelnfo" command issued by the management 
station. One skilled in the art will appreciate that the 

35 "GetConfigChangelnfo" command is merely an exam- 
ple of a specific command that may be used and that 
any other suitable command which server 1302 and 
storage system 1 304 can interpret as a command to be- 
gin the event notification process can be used. In addi- 

40 tion, the example illustrated in Fig. 13 is an event noti- 
fication example for a proxy attached storage system 
connected to a network through a server. A similar event 
notification process can be used with a network at- 
tached storage system, except that instead of the RPC 

45 command first being converted to UTM before being 
sent to the storage system, the network attached stor- 
age system will receive the "GetConfigChangelnfo" 
command in RPC form from the management station 
and processors it accordingly. That is, a RPC-to-internal 

50 messaging component receives the command and 
starts the managing AEN event. 

Configuration Update Notification 

55 [0093] In accordance with a preferred embodiment of 
the present invention, when a managed entity, such as 
a storage system or other suitable I/O device on a net- 
work undergoes a configuration change, it is preferable 
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that the configuration change for that managed device 
is broadcast to all management entities on the network. 
As discussed above, a given network can have a 
number of management entities such a one or more 
management stations in accordance with the present in- 
vention, as well as DMI, SNMP or other third party man- 
agement stations. Thus it is preferable to have a system 
and a method in which a managed entity can notify all 
management entities on a system of a configuration 
change. In accordance with this preferred aspect of the 
present invention, a flow diagram 1400 is shown illus- 
trating a process in which a managed entity 1404 in- 
forms all management entities 1 402 on a system of con- 
figuration changes. 

[0094] As discussed above, a role of the management 
entity 1402 is to keep and maintain an internal repre- 
sentation of the state of managed entities 1404 on the 
system. This internal representation of a managed entity 
1404 is referred to as an "object graph." Management 
entity 1402 builds the object graph by importing state 
information from managed entity 1404. In accordance 
with a preferred embodiment of the invention, when the 
configuration of a managed entity 1404 changes, the 
managed entity 1404 preferably transmits an entirely 
new object graph to management entity 1402. Manage- 
ment entity 1402 then uses the new object graph to up- 
date the visual representation of the managed entity on 
a display screen. 

[0095] I n accordance with an alternative embodiment 
of the present invention, instead of transmitting entirely 
new object graphs to management entity 1 402 when a 
configuration changes, management entities 1404 pref- 
erably update the object graphs in management entity 
1402 by transmitting call back deltas. These deltas 
specify the specific part(s) of the object graph which 
have changed, so that as small changes to the object 
graph are made, only the information about the small 
changes to the object graph are sent to management 
entities 1402, not completely new objects graphs. This 
allows the object graph changes to be localized, and 
thus, state information transfers minimized. 
[0096] For example, as discussed above with refer- 
ence to Figs. 9-13, when a management interface ap- 
plication is run for a particular managed device or entity, 
such as a storage system, the object graph of that stor- 
age system or managed entity is typically displayed on 
the management station. When changes to the man- 
aged entity are performed by a management station, 
such as volume creation (Fig. 9) or configuration chang- 
es (Figs. 10-12), the new configuration information typ- 
ically is transmitted back to the management station re- 
questing that change when the configuration change is 
complete. However, in accordance with this particular 
aspect of the present invention, it is preferable that the 
updated object graph deltas are independent from the 
configuration change requests. That is, when a man- 
agement station issues a configuration change com- 
mand, it does not wait for the command to finish before 
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performing other tasks. Instead, the management sta- 
tion preferably issues an event notification session as 
discussed above with reference to Fig. 1 3, and receives 
object graph update deltas via that path. In addition, all 

5 other management stations also will have event notifi- 
cation sessions running, so that they also will receive 
the object graph update deltas when the updates occur. 
In this manner, all management stations are updated 
with configuration change information as the changes 

w occur or shortly thereafter. In addition, the management 
station issuing the change request is not held-up, wait- 
ing for the change to occur. 

[0097] As illustrated in Fig. 1 5, a process flow 1 500 of 
a management entity sending configuration change 
is commands and receiving configuration change notifica- 
tion information is illustrated. In accordance with this as- 
pect of the present invention, the management entity 
preferably includes a user interface 1502, which allows 
a user to visualize the configuration and status of the 
managed devices on the system, as well as issue man- 
agement commands such as volume changes, config- 
uration changes, and/or error recovery commands, to 
name a few. To visualize the configuration and status of 
a particular managed device, user interface 1502 dis- 
plays an object graph 1504 of the particular managed 
device. When a user wishes to change the configuration 
of a particular managed device, the user, using interface 
1502, preferably issues one or more configuration 
change commands from a command issuer 1506. As 
illustrated in Fig. 1 5, when command issuer 1 506 issues 
a configuration change or error recovery command, it 
does not wait to receive the configuration change infor- 
mation from the managed device. Instead, the manage- 
ment entity preferably includes an event notification re- 
ceiver 1 508, which is configured to receive that informa- 
tion. When the managed device's configuration is up- 
dated, the managed device issues update notifications 
to all management entities on the system/network. The 
management entities receive these notifications via 
event notification receiver 1508. As discussed above, 
the update notifications from the managed devices may 
comprise entirely new object graphs from the managed 
devices, or the update notifications may be configura- 
tion deltas which merely reflect the change in the con- 
figuration. 

Long-Term Operations 

[0098] When performing configuration altering com- 
mands to a managed device such as a storage system 
or the like, two models of completion are common. The 
first model involves a command which only takes a short 
time to complete. With this model, the storage system 
controller can return status of the short-term configura- 
tion request to the requester, as well as other manage- 
ment devices in a system in near real time. The second 
model, however, involves a request that requires an ex- 
tended time to complete. For example, a complete refor- 
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mat or re-layout of data on a storage system. The prob- 
lem with an extended time to complete type request is 
that the user expects to see a progress indication of the 
command request to avoid uncertainty of a "hung" sys- 
tem. However, if a management station thread is left 
open to monitor the progress of the long term event, re- 
sources may be wasted because a management station 
thread is hung-up monitoring the status of the long-term 
command. Thus, in accordance with the present inven- 
tion, systems and methods are provided in which typi- 
cally long-lived operations are turned into short-term 
events. 

[0099] In a typical transaction model for storage ar- 
rays, a management station will not be freed until the 
storage array "commits" a particular request or transac- 
tion. When a storage system commits a transaction, the 
transaction typically is "durable". A durable transaction 
means that the storage system guarantees that subse- 
quent faults or interruptions on the storage system will 
not affect the results of the transaction. However, in ac- 
cordance with the present invention, just because a par- 
ticular transaction is durable does not mean that the 
storage system has finalized processing of the transac- 
tion, and thus, updated its configuration. As one skilled 
in the art may appreciate, a transaction can commit ear- 
ly, but the transaction may still have residual activities 
that go on within the storage system after the storage 
array has committed the transaction. These residual ac- 
tivities do not affect object durability, but may affect ob- 
ject state. That is, the transaction request may be dura- 
ble, but the storage system reconfiguration may not be 
complete. 

[0100] Referring now to Fig. 1 6, a flow diagram 1600 
is shown illustrating a method of processing long-lived 
operations. In accordance with flow diagram 1 600 in Fig. 
16, a host or a management station preferably issues a 
long-lived operation request, such as a storage system 
drive reconfiguration, or the like, to a managed device's 
controller (step 1 602). In accordance with this example, 
the managed device preferably is a storage system. 
However, any suitable managed device on a network 
may perform the long-lived processing operation of the 
present invention. 

[0101] After the management station issues the long- 
lived operation request, the controllerof the storage sys- 
tem receives the request (step 1604), processes the re- 
quest, and makes necessary state changes to make the 
long-lived operation "durable" (step 1606). While the 
storage system controller is processing the request, and 
making the operation durable, the management station 
preferably waits for a response from the controller indi- 
cating that the request is durable (step 1608). After the 
long-lived operation is durable in the storage system 
controller, the controller preferably returns status to the 
management station (step 1610). The management sta- 
tion receives the return status as complete (step 1612) 
and displays a status complete dialogue to the user re- 
questing the long-lived operation (step 1614). 



[0102] In accordance with the present invention, even 
though storage system controller returns status as com- 
plete, the complete status only indicates that the long- 
lived operation is durable within the controller. It does 

s not mean that the actual long-lived operation has com- 
pleted. Thus, the controller continues to process the 
long-lived operation (step 1616) and send status up- 
dates of the operation to the management station or host 
(step 1618). The management station receives the sta- 

10 tus updates and preferably updates the completion sta- 
tus dialogue object displayed on the screen of the man- 
agement station (step 1620). Steps 161 8 and 1620 con- 
tinue until the long-lived operation completes. Once the 
long-lived operation completes, the storage system con- 

is troller sends a completion message to the management 
station (step 1 622). Upon receiving the completion mes- 
sage from the controller, the management station noti- 
fies the user that the operation is complete (step 1624). 
The management station may inform the user that the 

20 operation is complete in a number of ways, including 
showing the completion status percentage as 100%, is- 
suing a dialogue stating that the operation is complete, 
or ending the process. In any event, any particular status 
completion message may be used. 

25 [0103] Even though in step 1620 the management 
station receives status updates, and updates the com- 
pletion status dialog on the management station screen, 
the management station is not frozen while waiting for 
the completion of the long-lived operation. That is, even 

30 though the management station displays the status in- 
formation, a user may perform other tasks with the man- 
agement station while the long-lived operation is 
processing. In addition, once the management station 
receives the message that the long-lived operation is 

35 "durable" even if the storage system fails, for example, 
due to power loss or some other mechanical error, the 
long-lived operation will be processed when the failed 
device is brought back on-line. In this matter, once an 
operation is made durable, the management station 

40 preferably does not ever have to issue the long-lived op- 
eration request again, regardless of what happens to the 
controller. 

Conclusion 

45 

[0104] In conclusion, the present invention provides 
methods and apparatus for managing I/O devices on a 
network. While a detailed description of presently pre- 
ferred embodiments of the present invention have been 

50 given above, various alternatives, modifications and 
equivalents will be apparent to those skilled in the art. 
For example, while most of the examples given herein 
refer to storage systems, any suitable I/O device resid- 
ing on a network may be managed using the methods 

55 and apparatus of the present invention without varying 
from the spirit of the invention. In addition, while pre- 
ferred embodiments of the present invention are dis- 
closed herein as using Java applets and Java compliant 
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browsers or run-time environments to process the Java 
applets, any suitable computer language and process- 
ing environment may be used. Therefore, the above de- 
scription should not be taken as limiting the invention 
which is defined by the appended claims. 

Claims 

1. A system for monitoring and managing devices on 
a network, comprising: 

a proxy server connected to said network; 
a managed device connected to said proxy 
server via a communication connection; 
storage means for storing a device manage- 
ment application program associated with said 
managed device; and 

a management station in communication with 
said managed device via said proxy server and 
in communication with said storage means, 
said management station configured to retrieve 
said device management application program 
from said storage means and process said de- 
vice management application program; 

wherein the processing of said device man- 
agement application program by said management 
station allows said management station to monitor 
and manage said managed device. 

2. The system as recited in claim 1 , wherein said man- 
aged device is connected to said proxy server by a 
communication connection selected from the group 
of communication connections including peripheral 
component interconnect (PCI), small computer sys- 
tem interface (SCSI), universal serial bus (USB), fi- 
bre channel, andfirewire. 

3. The system as recited in claim 1 , wherein said man- 
aged device includes a controller for controlling said 
managed device, and wherein the processing of 
said device management application program by 
said management station allows said management 
station to send management commands to said 
controller via said proxy server. 

4. The system as recited in claim 3, wherein said man- 
aged device is a storage system. 

5. The system as recited in claim 3, wherein said proxy 
server comprises routing means for receiving com- 
mands from said management station and routing 
said commands to said controller of said managed 
device. 

6. The system as recited in claim 5, wherein said de- 
vice management application program communi- 
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cates with said proxy server using a first communi- 
cation protocol, and said proxy server communi- 
cates with said managed device using a second 
communication protocol, and wherein said proxy 

5 server comprises a protocol converter for convert- 
ing communication messages directed from said 
device management application program to said 
managed device from said first communication pro- 
tocol to said second communication protocol, and 

10 for converting communication messages directed 
from said managed device to said device manage- 
ment application program from said second com- 
munication protocol to said first communication pro- 
tocol. 

15 

7. The system as recited in claim 6, wherein said first 
communication protocol is remote procedure call 
(RPC) and said second communication protocol is 
universal transport mechanism (UTM), and wherein 

20 said protocol converter comprises an RPC-to-UTM 
conversion application. 

8. The system as recited in claim 6, wherein said con- 
troller comprises a second protocol converter for 

25 converting said second communication protocol in- 
to a management protocol which said controller of 
said managed device can process. 

9. The system as recited in claim 3, wherein said proxy 
30 server includes a device mapper, which locates de- 
vices connected to said proxy server and assigns a 
TCPMP port to each of said devices. 

10. The system as recited in claim 9, wherein when said 
35 device management application program sends 

said management commands to said controller of 
said managed device, said device management ap- 
plication program first sends said management 
commands to said proxy server and said device 
40 mapper in said proxy server routes said manage- 
ment commands to said managed device. 

11 . The system as recited in claim 1 , wherein said proxy 
server further comprises a desktop management in- 

4 5 terface (DMI) interface, which facilitates communi- 
cation between said managed device and a DMI 
management station. 

12. The system as recited in claim 1 , wherein said proxy 
so server further comprises a simple network manage- 
ment protocol (SNMP) interface, which facilitates 
communication between said managed device and 
an SNMP management station. 

55 1 3. The system as recited in claim 1 , wherein said man- 
agement station comprises java processing means 
for processing java applets or applications, and 
wherein said device management application pro- 
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grams comprise java applets. 

1 4. The system as recited in claim 1 , wherein a plurality 
of managed devices are connected to said proxy 
server. 

1 5. The system as recited in claim 1 , wherein said man- 
aged device may be connected to a plurality of 
proxy servers. 

16. A system for monitoring and managing storage de- 
vices on a network, comprising: 

a proxy server connected to said network; 
a storage device connected to said proxy serv- 
er, said storage device including a controller; 
storage means for storing a device manage- 
ment application program associated with said 
storage device; and 

a management station in communication with 
said storage device via said proxy server and 
in communication with said storage means, 
said management station configured to retrieve 
said device management application program 
from said storage means and process said de- 
vice management application program; 

wherein the processing of said device man- 
agement application program by said management 
station allows said management station to monitor 
said storage device and send management com- 
mands to said controller of said storage device via 
said proxy server. 

17. The system as recited in claim 1 , wherein said man- 
agement station comprises java processing means 
for processing java applets or applications, and 
wherein said device management application pro- 
grams comprise java applets. 

18. A method for managing devices connected to a 
proxy server, comprising the steps of: 

(a) providing a proxy server connected to a net- 
work; 

(b) providing a management station for manag- 
ing one or more managed devices connected 
to said proxy server; 

(c) said management station locating said 
proxy server on said network; 

(d) said management station obtaining from 
said proxy server a list of said one or more man- 
aged devices connected to said proxy server; 

(e) displaying said one or more managed de- 
vices connected to said proxy server on a dis- 
play associated with said management station; 

(f) selecting one of said one or more managed 
devices to be managed; 
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(g) retrieving a management application pro- 
gram associated with said selected one of said 
one or more managed devices from a storage 
means; 

5 (h) running said retrieved management appli- 

cation program on said management station; 
and 

(i) sending management commands from said 
management station to said selected one of 
10 said one or more managed devices via said 

proxy server. 

19. The method as recited in claim 18, wherein said 
proxy server comprises routing means for receiving 

is said management commands from said proxy serv- 
er and routing said management commands to said 
selected one of said one or more managed devices. 

20. The method as recited in claim 18, wherein said 
20 management station communicates with said proxy 

server with a first communication protocol and said 
proxy server communicates with said selected one 
of said one or more managed devices with a second 
communication protocol, and wherein said method 
25 further comprises the steps of: 

(j) said proxy server converting said manage- 
ment commands from said management sta- 
tion from said first communication protocol for- 
30 mat to said second communication protocol for- 

mat; and 

(k) said proxy server sending said management 
commands to said selected one of said one or 
more managed devices in said second commu- 
35 nication protocol format. 

21. The method as recited in claim 20 wherein said first 
communication protocol is remote procedure call 
(RPC) and said second communication protocol is 

40 universal transport mechanism (UTM). 

22. The method as recited in claim 20, further compris- 
ing the steps of: 

45 (|) said selected one of said one or more man- 

aged devices converting said management 
commands in said second communication pro- 
tocol format to a management protocol com- 
mand which a controller of said selected one of 

50 said one or more managed devices can proc- 

ess; and 

(m) said selected one of said one or more man- 
aged devices processing said management 
protocol command. 

55 

23. A method for monitoring devices connected to a 
proxy server, comprising the steps of: 



EP 1 067 732 A2 



19 



37 



EP 1 067 732 A2 



38 



(a) providing a proxy server connected to a net- 
work; 

(b) providing a management station for moni- 
toring one or more managed devices connect- 
ed to said proxy server; 

(c) said management station locating said 
proxy server on said network; 

(d) said management station obtaining from 
said proxy server a list of said one or more man- 
aged devices connected to said proxy server; 

(e) said management station retrieving from 
each of said one or more managed devices an 
object graph, said object graph representing a 
configuration and a status of said one or more 
managed devices; 

(f) displaying said object graph of said one or 
more managed devices on a display associated 
with said management station; and 

(g) monitoring said network for event notifica- 
tions transmitted by any of said one or more 
managed devices. 



said display. 

30. The method as recited in claim 24, wherein said 
event monitoring application comprises a hanging 
asynchronous event notification (AEN) application. 
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24. The method as recited in claim 23, further compris- 
ing the steps of: 

(h) said management station initiating an event 
monitoring application on any of said one or 
more managed devices; and 

(i) when an event on said any of said one or 
more managed devices occurs, said event 
monitoring application transmitting event notifi- 
cations to said management station of said 
event. 
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25. The method as recited in claim 24, wherein the step 35 
of said management station initiating an event mon- 
itoring application comprises the steps of starting a 
proxy communication thread on said proxy server, 
which then starts the event monitoring application 
on said any of said one or more managed devices. 40 



26. The method as recited in claim 24, wherein said 
event comprises a configuration change of said any 
of said one or more managed devices. 

27. The method as recited in claim 24, wherein said 
event comprises a status changes of said any of 
said one or more managed devices. 
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28. The method as recited in claim 24, wherein said 
event comprises an error of said any of said one or 
more managed devices. 
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29. The method as recited in claim 24, wherein when 
said management station receives said event noti- 
fication from said event monitoring application, said 
management station updates said object graph for 
said any of said one or more managed devices on 
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